Systems and methods to provide secure storage

ABSTRACT

Systems and method to provide secure storage are disclosed. An example method includes establishing a secure tunnel between a storage device and an agent, provide a command from the agent to the storage device via the secure tunnel, access first data at the storage device in response to the command, and identify a modification to data stored on the storage device by comparing the first data to second data, wherein the comparison is done using the storage device.

RELATED APPLICATIONS

This patent arises from a continuation of U.S. patent application Ser.No. 14/818,654, filed Aug. 5, 2015, which is a continuation of U.S.patent application Ser. No. 13/630,043, filed on Sep. 28, 2012, now U.S.Pat. No. 9,135,446, entitled “SYSTEMS AND METHODS TO PROVIDE SECURESTORAGE.” U.S. patent application Ser. No. 14/818,654 and U.S. patentapplication Ser. No. 13/630,043 are hereby incorporated herein byreference in their entireties.

FIELD OF THE DISCLOSURE

This disclosure relates generally to storage devices, and, moreparticularly, to systems and methods to provide secure storage.

BACKGROUND

Today, host side applications (e.g. antivirus software) use an operatingsystem application programming interface (API) to read in data (e.g.malware definition data) from storage to detect malware. Additionally,other storage specific commands can be used to read, write, andotherwise manage stored data. For example, vendor specific commands,SMART Command Transport (SCT), negative logical block addresses (LBA),etc., can be used to process stored data. These methods can be subvertedby malware to give wrong information to a data requester. In addition,there is no provision for configuring the methods to provide applicationspecific protection. Furthermore, data that is stored can be attacked bymalware and may be copied or altered.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example platform constructed inaccordance with the teachings of this disclosure to perform secure dataintegrity checks.

FIG. 2 is a block diagram of another example platform constructed inaccordance with the teachings of this disclosure to perform secure dataintegrity checks.

FIG. 3 is a flowchart representative of example machine readableinstructions which may be executed to implement the example platform ofFIG. 1 to perform secure data integrity checks.

FIG. 4 is a flowchart representative of alternative example machinereadable instructions which may be executed to implement the exampleplatform of FIG. 2 to perform secure data integrity checks.

FIG. 5 illustrates an example agent to communicate information to asecure storage system using a tunnel in accordance with the teachings ofthis disclosure.

FIG. 6 illustrates another example agent to communicate information to asecure storage system using a tunnel in accordance with the teachings ofthis disclosure.

FIG. 7 illustrates an example communication from an agent to a securestorage system using mailboxing in accordance with the teachings of thisdisclosure.

FIG. 8 illustrates an example communication from a secure storage systemto an agent using mailboxing in accordance with the teachings of thisdisclosure.

FIG. 9 is a flowchart representative of example machine readableinstructions which may be executed to implement the example data storagedevice of FIGS. 1 and/or 2 to communicate information between the datastorage device and an agent using mailboxing.

FIG. 10 is a flowchart representative of example machine readableinstructions which may be executed to implement the example data storagedevice of FIGS. 1 and/or 2 to process mailboxing communication commands.

FIG. 11 is a flowchart representative of example machine readableinstructions which may be executed to implement the example data storagedevice of FIGS. 1 and/or 2 to process tunnel messages that aretransmitted using secure Serial Advanced Technology Attachment (SATA).

FIG. 12 illustrates a block diagram of a file awareness block toimplement the example file awareness block of FIG. 2.

FIG. 13 illustrates a more detailed block diagram of the example devicelevel file system of FIG. 12.

FIG. 14 is a flowchart representative of example machine readableinstructions which may be executed to implement the example data storagedevice of FIG. 2 to perform trusted operations on a system.

FIG. 15 is a block diagram of an example computer capable of executingthe instructions of FIGS. 3, 4, 9-11, and 14 to implement the platformsof FIGS. 1 and/or 2.

FIG. 16 is a block diagram of an example system-on-a-chip capable ofexecuting the instructions of FIGS. 3, 4, 9-11, and 14 to implement thedata storage devices of FIGS. 1 and/or 2.

DETAILED DESCRIPTION

Sophisticated malware (e.g., kernel rootkits and/or virtual rootkits) iscapable of controlling virtually everything within a processing systemexcept for the actual scheduling of processing time within the system.Malware can attack stored data and can subvert operating system calls toa storage system. Such malware can cause the return of any type of datain response to requests for data from applications (e.g., modifiedversions of actual data). Advanced rootkits may be able to subvertverification procedures (e.g., malware detection and/or integrity-checkprocedures) by presenting unmodified copies of data (e.g., files) forinspection by such procedures by, for example, masking the presenceand/or contents of files.

Example methods, apparatus, and/or articles of manufacture disclosedherein create a secure tunnel between an agent (e.g., a softwareapplication) and a secure storage system within a data storage device.In some examples, the secure storage system hides the data storage byencrypting the data communicated to the secure storage system andstoring data beyond the accessibility of an operating system. In someexamples, a data storage device provides a trusted view of raw (e.g.,unadulterated) data that is physically committed to a non-volatilemedium in the data storage device via a trusted application programminginterface (API) to an agent (e.g., an application running on a host CPU,a remote agent, etc.). In some such examples, firmware is used to managethe data storage device. Example firmware runs in a protectedenvironment (e.g., a closed, isolated and/or secure environment) with aroot of trust. Agents running on the host platform of the storagedevices or remote agents communicate through a trusted tunnel to accessthe firmware and/or software used to manage the data storage devicesubsystems. In some examples, agents are permitted to operate (e.g.,read and/or write) on raw block level information (e.g., at the file,folder or disk level) and/or on metadata based on file systeminformation.

Example agents disclosed herein can detect malware (e.g., rootkits) byaccessing the raw, unadulterated data committed to the storage media viathe trusted tunnel (e.g., trusted data) and accessing thepotentially-modified information via normal channels (e.g., visibledata), and comparing the trusted data to the visible data. Using thetrusted tunnel, agents can access unencrypted and encrypted informationand/or digital signatures (e.g., hashes) of the trusted data and/or thevisible data. By using the trusted tunnels, the agents can be assuredthat the data obtained via the trusted tunnel has not been altered(e.g., masked, hidden) by malware.

In some examples, an agent compares the raw data obtained using thetrusted tunnel to baselines of trusted data. In some examples, an agentgenerates cryptographic hashes (e.g., signatures) of raw data obtainedvia the trusted tunnel to cryptographic hashes of white-listed files ordata.

In some examples, an agent executing in the firmware or softwareexecuting on a secure processing element of a data storage devicecompares raw data to tainted data and/or baseline data. In someexamples, the agent executing in the firmware or software executing on asecure processing element of a data storage device generates andcompares cryptographic hashes of the raw data. In some examples, theagent executing on the data storage device receives commands via atrusted tunnel from a second agent operating on a host or a remoteagent. In examples in which the agent executing on the data storagedevice performs the comparison and/or the generation, the agent executesin a more protected environment than an agent executing on the host. Forexample, firmware containing the agent can be provisioned and/oractivated at the time of assembly of the data storage device, and priorto exposure of the data storage device to systems afflicted with malwareand/or undesired data modification.

Example methods, apparatus, and computer readable storage mediadisclosed herein enable security service providers to improve therobustness, effectiveness, and/or scalability of data integrity toolsand solutions.

As used herein, a “host” refers to a host processing platform of which astorage medium or device constructed in accordance with the teachings ofthis disclosure is a part. A host may include any combinations ofhardware, software, firmware, and/or interfaces to enable the host andthe subject storage device to interface.

FIG. 1 is a block diagram of an example platform 100 to perform securedata integrity checks. The example platform 100 of FIG. 1 includes adata storage device 102, an operating system 104, and an independentsoftware application such as a data integrity checking application 106.

The operating system 104 is an operating system such as MicrosoftWindows®, Apple® OS X®, etc. In the example of FIG. 1, the operatingsystem 104 includes a private software developer's kit (SDK) 108, a filesystem 110, a driver stack 112, and an application 114. The example filesystem 110 is used to manage files that are stored in the data storagedevice 102. For example, the file system 110 may specify the manner inwhich the operating system 104 is to organize data in the storage device102 using the driver stack 112. The example driver stack 112 is a set ofdriver(s) used by the operating system 104 and/or the application 114 tointeract with data storage device 102 (e.g., read and write data). Thedriver stack 112 may include multiple software layers in the form ofdrivers that take on different functional roles and act as an overallinterface between an application or process and one or more storagedevices.

Like the data integrity checking application 106, the exampleapplication 114 of FIG. 1 is an application that runs in the operatingsystem 104. One example of an application can be an e-mail client, aword processor, an image management application, a media managementapplication, anti-virus software, operating system functions, and/or anyother type of application. Each application may interact with thestorage system 102 using the file system 110 and the driver stack 112.

The example data storage device 102 of FIG. 1 includes data storagedevice firmware 116, a system-on-a-chip (SOC) 118, memory 120, and astorage area 122. The data storage device 102 can be any type of storagedevice (e.g., solid state drives (SSD), hard disks (HD), flash drives(FD), etc.). The example system-on-a-chip 118 is a chip that includes aprocessor and other circuits that are used to support the data storagedevice 102 (e.g., by executing the firmware 116). An exampleimplementation of the SOC 118 is further described below in FIG. 17below. The example memory 120 is memory used to temporarily store data.The data storage device firmware 116 is firmware that may be executedoperate and manage the different functions of the data storage device102.

The example storage area 122 of FIG. 1 includes a secure storage area124. The secure storage 124 is not visible to the operating systemthrough the file system 110 and/or the driver stack 112. The examplestorage area 122 further includes a visible (e.g., OS-visible) storage126 which, in contrast to the secure storage area 124, is visible andaccessible to the OS 104 and/or the application 114. The visible storage126 may be implemented using known storage devices.

The example data storage device firmware 116 of FIG. 1 includes atrusted application programming interface (API) 128 and a trusted systemfirmware 130. The trusted API 128 is used by processes executing in theoperating system 104 and/or by trusted applications, such as the dataintegrity check application 106, to access the secure storage 124. Thetrusted system firmware 130 is firmware that is executed to manage thesecure storage 124. The example trusted API 128 is accessed by localand/or remote entities to create a secure tunnel between that entity andthe secure storage. A tunnel is used to securely transmit information(e.g., read and/or write data) between an entity and the secure storage124. For example, the data integrity check application 106 may create atunnel 132 via trusted API 128 and the trusted system firmware 130 tothe secure storage 124.

The secure storage 124 stores data that is invisible to the operatingsystem 104 and, therefore, cannot be accessed by low-level rootkits thatdo not have a root-of-trust. For example, the secure storage 124 of FIG.1 exists at storage addresses that are beyond the maximum addressablestorage available to the operating system 104 and/or applications 114that are accessing the data storage device 102 via the file system 110and driver stack 112. The example secure storage 124 may be physicallyseparate from the visible storage 126 or may be a partition of thevisible storage 126.

In the example of FIG. 1, the secure storage 124 stores important data,such as data that may be used to identify malicious changes and/ornon-malicious but undesired changes to data. For example, the securestorage 124 stores baseline data 134 (e.g., data files, executables,and/or databases), secure hashes 136 of the baseline data 134, and/ornon-secure hashes 138 of the baseline data 134. The example securehashes 136 and the non-secure hashes 138 are hashes or signaturesperformed by the example data integrity check application 106. Thesecure hashes 136 are generated based on secure transmission of thebaseline data 134 from the secure storage 124 to the data integritycheck application 106 and secure transmission of the secure hashes 136from the data integrity check application 106 to the secure storage 124via the tunnel 132, the trusted API 128, and the trusted system firmware130. In contrast, the non-secure hashes 138 are generated based on datathat is potentially subject to manipulation (e.g., data 140 such asfiles, executables, and/or databases store in the visible storage 126).

As described above, the data in the secure storage 124 is not visible toan application except through the trusted API 128. In the example ofFIG. 1, the data integrity check application 106 accesses the securestorage 124 using the tunnel 132 (via the private SDK 108, the trustedAPI 128, and the trusted system firmware 130). The example dataintegrity check application 106 is a trusted agent that is permitted tosecurely read data from and write data to the secure storage area 124.The data stored in the secure storage 124 (e.g., the baseline files 134,the secure hashes 136, and the non-secure hashes 138) is invisible tothe OS 104 and to application(s) 114 executing in the operating system104. Therefore, neither the OS 104 nor the application 114 can view,alter, or delete the data stored in secure storage 124. Additionally,malware executing at or above the OS 104 level cannot view, alter, ordelete the data stored in the secure storage 124. As a result, theexample data storage device 102 provides a trusted view of baseline data(e.g., files, blocks, and/or other units of data) and/or hashes(signatures) of data for comparison to potentially tainted data orhashes of such data. An agent can then use this comparison to identifythe presence of malicious modifications to data and/or non-malicious butundesired modifications to data (e.g., by searching for signaturechanges to data indicative of such modifications).

The example trusted API 128 may form the tunnel 132 by, for example: (1)a mailboxing scheme in which logical block addresses are set aside forcommunication between the agent (e.g., the data integrity checkapplication 106) and the data storage device 102 (e.g., the trusted API128), and/or (2) trusted sends (e.g., messages sending data from a hostto a storage device according to a specified security protocol, messagessending data from a host to a storage device according to TrustedComputing standards, and/or messages sending data from a host to astorage device using another method of verifying trust) and trustedreceives (e.g., messages retrieving data from a storage device accordingto a specified security protocol and corresponding to a trusted send,messages retrieving data from a storage device according to TrustedComputing standards, and/or messages retrieving data from a storagedevice using another method of verifying trust) that are supported bythe data storage device 102 (e.g., the trusted API 128 and/or thetrusted system firmware 130).

In the example of FIG. 1, the tunnel 132 is formed between the trustedAPI 128 and the agent 106 running on the host (e.g., the same computeror other platform) that includes the data storage device 102. In someother examples, a trusted tunnel 144 may be formed between the datastorage device (e.g., via the trusted API 128) and a remote agent 146(e.g., a remote server) that is coupled to the platform 100 via anetwork 148. In some such examples, the trusted system firmware 130 (viathe trusted API 128) creates a network connection 150 that is used tocommunicate information with the remote agent 146. For example, thetrusted storage firmware 130 may create the trusted tunnel 144 such thatthe remote agent 146 may read and/or write data to the secure storage124 of the data storage device 102. By establishing the trusted tunnel144 to a remote agent 146, a remote agent 146 such as a network monitormay monitor malicious and/or undesired changes to data on multiple datastorage devices, including the data storage device 102, that areconnected to the network 148.

The example data integrity check application 106 of FIG. 1 performs dataintegrity checks of the data stored on the data storage device 102. Theexample data integrity check application 106 includes a hash generator152, a data integrity checker 154, a report generator 156, and trustedoperations 158.

The example hash generator 152 generates cryptographic hashes of thebaseline data 134 (e.g., secure hashes 136) and/or cryptographic hashesof the visible data 140 (e.g., non-secure hashes 138). The dataintegrity checker 154 compares the secure hashes 136 to the non-securehashes 138 to determine whether any changes have occurred. Additionallyor alternatively, the data integrity checker 154 compares the baselinedata 134 to the visible data 140 to determine whether changes haveoccurred. The example hash generator 152 and/or the example dataintegrity checker 154 may operate periodically, aperiodically, inresponse to an event, on demand, and/or at any other time to identifychanges to the data 140.

The example data integrity check application 106 (e.g., the hashgenerator 152 and/or the data integrity checker 154) uses the exampletrusted operations 158 to securely communicate with the secure storage124 (e.g., via the tunnel 132, the trusted API 128, and/or the trustedsystem firmware 130). Example trusted operations 158 include a trustedread operation and a trusted write operation. In the example of FIG. 1,a trusted read or trusted write means that the identity of the entityrequesting the operation is known and trusted. Trust may be establishedby requiring the data integrity check application 106 to sign trustedread requests and/or trusted write requests using a trusted signature160. Example methods to securely communicate data between the dataintegrity check application 106 and the secure storage 124 via thetunnel 132 are described below.

The example hash generator 152 may use the trusted operations 158 toread the baseline data 134 from the secure storage and/or to write thesecure hashes 136 and/or the non-secure hashes 138 to the secure storage124. Additionally or alternatively, the data integrity checker 154 mayuse the trusted operations 158 to read the baseline data 134, the securehashes 136, and/or the non-secure hashes 138 from the secure storage124.

The example report generator 156 of FIG. 1 generates reports based oninformation from the data integrity checker 154. To generate thereports, the report generator 156 may apply rules to the differencesidentified by the data integrity checker 154 between raw data and/orcryptographic hashes. Example rules may include differences between datathat match signature behaviors of known malware. The example reportgenerator 156 provides generated reports for system administratorsand/or managers to evaluate the differences in data and/or to initiatecorrective action.

FIG. 2 is a block diagram of another example platform 200 to performsecure data integrity checks. The example platform 200 of FIG. 2includes a data storage device 202, an operating system 204, and a dataintegrity check application 206. Compared to the platform 100 of FIG. 1,the example platform 200 performs more data operations (e.g., hashingdata, comparing data to baseline data and/or secure hashes to non-securehashes, etc.) on the data storage device 202 than on the data storagedevice 102.

The example data storage device 202 of FIG. 2 includes the example SOC118, the example memory 120, and the example storage area 122 of FIG. 1.The example storage area 122 includes the example secure storage 124(which stores the baseline data 134, the secure hashes 136, and thenon-secure hashes 138, among other things) and the OS-visible storage126 of FIG. 1 (which stores visible data 140).

The example data storage device 202 further includes data storage devicefirmware 208. The example data storage device firmware 208 includes thetrusted API 128 and the trusted system firmware 130 of FIG. 1. Unlikethe data storage device firmware 116 of FIG. 1, the example data storagedevice firmware 208 of FIG. 2 further includes a hash generator 210, adata integrity checker 212, and embedded file awareness firmware 214.

The example hash generator 210 of FIG. 2 may be similar or identical tothe example hash generator 152 of FIG. 1. In particular, the examplehash generator 210 obtains copies of data (e.g., baseline data 134and/or visible data 140) and generates hashes or signatures of the datato generate secure hashes 136 and/or non-secure hashes 138. The securehashes 136 and/or non-secure hashes 138 may be securely stored in thesecure storage 124 (e.g., via the trusted system firmware 130).

The example data integrity checker 212 of FIG. 2 may be similar oridentical to the example data integrity checker 154 of FIG. 1. Inparticular, the example data integrity checker 212 executes securely inthe data storage device firmware 208 and compares the secure hashes 136to the non-secure hashes 138 and/or compares the baseline data 134 tothe visible data 140 to determine whether changes have occurred.

The example embedding file awareness firmware 214 translates rawinformation (e.g., bits and bytes) for use by the data storage devicefirmware 208. The example OS 204 and the example data integrity checkapplication 206 include file awareness drivers 218. The file awarenessdrivers 218 enable the OS 204 and/or the data integrity checkapplication 206 to communicate file structure information to the datastorage device firmware 208 to instruct the embedded file awarenessfirmware 214 how to read and translate the types of files present in thesecure storage 124 and/or the visible storage 126. As a result, the datastorage device firmware 208 (e.g., the hash generator 210, the dataintegrity checker 212) may perform operations on the data 134-140without transferring the data to the OS 204 and/or the data integritycheck application 206 for interpretation of the raw bits and bytes.

The example OS 204 of FIG. 2 further includes the private SDK 108, thefile system 110, the driver stack 112, and the application 114 ofFIG. 1. In addition to the file awareness drivers 218, the example dataintegrity check application 206 of FIG. 2 includes a command generator220 and the report generator 156 of FIG. 1.

The example command generator 220 of FIG. 2 generates and transmitscommands to the data storage device firmware 208 via a secure tunnel 224and the trusted API 128. By using the secure tunnel 224, the examplecommand generator 220 may provide trusted commands to the example datastorage device firmware 208, including commands to read and/or writedata via the embedded file awareness firmware 214, to generate hashes ofparticular data and/or locations in the secure storage 124 and/or in thevisible storage 126, to provide definitions or signatures of changes todata to the data integrity checker 212, and/or to provide other securecommands and/or instructions. Similarly, the example command generator220 may receive data integrity check information from the data integritychecker 212 via the secure tunnel 224 and the trusted API 128.

In some examples, the embedded file awareness firmware 214 may receivecommands and/or file information from the remote agent 146 via thesecure tunnel 144, the network 148, and the network connection 150 ofFIG. 1.

The embedded file awareness firmware 214 receives communications from anagent (e.g., the application 114, the data integrity check application206) via the trusted API 128 to provide the awareness of the file system110 used by the OS 204 to the data storage device firmware 208. Theexample embedded file awareness firmware 214 includes a device filesystem 228 to support a subset of services provided by the OS filesystem 110. The example embedded file awareness firmware 214 enables thedata storage device firmware 208 to perform data integrity checks ondata in the storage device (e.g., a malware scan), perform trustedoperations in the storage device including a computation of hashes or acomparison of hash signatures, access a backup of the host file system110 stored on the data storage device 202, and/or perform other filesystem operations.

To provide file awareness, a set of synchronizing messages is sentbetween the OS 204 and/or the data integrity check application 206 viathe file awareness driver 218. The file awareness driver 218 isauthorized to communicate with the embedded file awareness firmware 214(e.g., via the trusted API 128). In the example of FIG. 2, a master copyof the file system is resident in the host (e.g., the file system 110 inthe OS 204). The file awareness driver 218 initiates the following setof messages to the data storage device firmware 208.

An Init_filesystem(file system) message causes the embedded fileawareness firmware 214 to initialize a structure in the storage area 122that refers to the specified host “file system.” An exampleInit_filesystem message includes “Init_filesystem(UFS1).”

A Set_fileupdate(file system, filename, properties, <LBA list>) messageprovides a file system, a file name within the specified file system,properties of the specified file, and an ordered list of logical blockaddresses containing the data associated with the specified file. TheSet_fileupdate message results in updating the file system on thestorage device with a file name-to-logical block address mapping for thespecified file name. An example Set_fileupdate message includes“Set_fileupdate(UFS1, explorer.exe, properties(hrwx,dr), <10, . . .112>),” where the “hrwx” argument indicates that the host (e.g., the OS204, the application 206) has permissions include reading, writing, andexecuting the file. The “dr” argument indicates that the storage device202 has permissions including reading the file.

A Get_fileupdate(file system, filename) message provides a file systemand a file name within the file system. The Get_fileupdate(file system,filename) message results in the data storage device 202 returning thedata associated with the specified file to the host (e.g., the OS 204,the application 206). The returned data includes changes to thespecified file that are cached in the storage device 202 (e.g., in acache 226). The size of the cache 226 may be based on expected usages ofthe storage device aware files. An example Get_fileupdate messageincludes “Get_fileupdate(UFS1, results.out).” The file system field ofthe Get_fileupdate message provides a pointer to a file system that isreferenced by the message to the embedded file awareness firmware 214(e.g., to distinguish between multiple file systems that may be presenton the data storage device 202).

The device file system organization is stored at the data storage device202. The files in the example file system are organized as a searchablecollection of file names. Each record (e.g., file name) in thecollection of file names point to the metadata associated with therespective record. The collection of file names may be implemented as aflat data structure with a sequential search to find a desired fileand/or as an indexed data structure with binary search support to accessand/or update a file.

The example file awareness drivers 218 communicate with the embeddedfile awareness firmware 214 via the trusted API 128 and the securetunnel 224. Therefore, the messages and responses are communicatedbetween the file awareness drivers 218 communicate with the embeddedfile awareness firmware 214 in a trusted environment that cannot beaccessed by malware. The example server may be used for provisioningkeys into the storage device for authentication and encryption purposes,setting and receiving data from the secure storage, and setting andreceiving trusted block level data when the ISV performs a remote scan.

In a client system such as a laptop computer or a tablet computer,communication between the file awareness drivers 218 and the embeddedfile awareness firmware 214 may be implemented using trusted-ATAcommands over SATA and/or using vendor-unique commands over SATA. Inclient systems such as a smartphone, the communications may beimplemented using trusted-ATA commands over embedded MultiMediaCard(eMMC). Other communication implementations may additionally oralternatively be used.

As used herein, using the trusted tunnels 132, 144, 224 includes usingappropriate ones of the trusted operations 158, the trusted signature160, the trusted API 128, the trusted system firmware 130, and/orprivate SDK 108, and/or any other intermediate pathways, operations,and/or interfaces to securely communicate via the tunnels 132, 144, 224.

While an example manner of implementing the platforms 100, 200 have beenillustrated in FIGS. 1, 2, 5-8, 12, and 13, one or more of the elements,processes and/or devices illustrated in FIGS. 1, 2, 5-8, 12, and 13 maybe combined, divided, re-arranged, omitted, eliminated and/orimplemented in any other way. Further, any or all of the example datastorage devices 102, 202, example operating systems 104, 204, exampledata integrity check applications 106, 206, example private SDK 108,example file system 110, example driver stack 112, example application114, example data storage device firmware 116, 208, examplesystem-on-a-chip 118, example memory 120, example storage area 122,example secure storage 124, example visible storage 126, example trustedAPI 128, example trusted system firmware 130, example secure tunnels132, 144, 224, example data 134, example secure hashes 136, examplenon-secure hashes 138, example remote agent 146, example hash generators152, 210, example data integrity checkers 154, 212, example reportgenerator 156, example trusted operations 158, example trusted signature160, example embedded file awareness 214, 1200, example file awarenessdrivers 218, example command generator 220, example cache 226, exampledevice file system 228, example agents 502, 602, 702, 802, examplesecure storage devices 504, 604, example LBAs 506, 508, 706, 806,example file awareness message handler 1202, example device level filesystem 1204, example device file properties 1302, example device filetables 1304, example device file system interface 1306, example NANDmanagement subsystem 1308, example device file system cache 1310 and/or,more generally, the example platforms 100, 200 of FIGS. 1 and/or 2 maybe implemented by hardware, software, firmware and/or any combination ofhardware, software and/or firmware. Thus, for example, any or all ofexample data storage devices 102, 202, example operating systems 104,204, example data integrity check applications 106, 206, example privateSDK 108, example file system 110, example driver stack 112, exampleapplication 114, example data storage device firmware 116, 208, examplesystem-on-a-chip 118, example memory 120, example storage area 122,example secure storage 124, example visible storage 126, example trustedAPI 128, example trusted system firmware 130, example secure tunnels132, 144, 224, example data 134, example secure hashes 136, examplenon-secure hashes 138, example remote agent 146, example hash generators152, 210, example data integrity checkers 154, 212, example reportgenerator 156, example trusted operations 158, example trusted signature160, example embedded file awareness 214, 1200, example file awarenessdrivers 218, example command generator 220, example cache 226, exampledevice file system 228, example agents 502, 602, 702, 802, examplesecure storage devices 504, 604, example LBAs 506, 508, 706, 806,example file awareness message handler 1202, example device level filesystem 1204, example device file properties 1302, example device filetables 1304, example device file system interface 1306, example NANDmanagement subsystem 1308, example device file system cache 1310 and/or,more generally, the example platforms 100, 200 could be implemented byone or more circuit(s), programmable processor(s), application specificintegrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s))and/or field programmable logic device(s) (FPLD(s)), etc. When any ofthe apparatus or system claims of this patent are read to cover a purelysoftware and/or firmware implementation, at least one of the exampledata storage devices 102, 202, example operating systems 104, 204,example data integrity check applications 106, 206, example private SDK108, example file system 110, example driver stack 112, exampleapplication 114, example data storage device firmware 116, 208, examplesystem-on-a-chip 118, example memory 120, example storage area 122,example secure storage 124, example visible storage 126, example trustedAPI 128, example trusted system firmware 130, example secure tunnels132, 144, 224, example data 134, example secure hashes 136, examplenon-secure hashes 138, example remote agent 146, example hash generators152, 210, example data integrity checkers 154, 212, example reportgenerator 156, example trusted operations 158, example trusted signature160, example embedded file awareness 214, 1200, example file awarenessdrivers 218, example command generator 220, example cache 226, exampledevice file system 228, example agents 502, 602, 702, 802, examplesecure storage devices 504, 604, example LBAs 506, 508, 706, 806,example file awareness message handler 1202, example device level filesystem 1204, example device file properties 1302, example device filetables 1304, example device file system interface 1306, example NANDmanagement subsystem 1308, and/or example device file system cache 1310are hereby expressly defined to include a tangible computer readablestorage medium such as a memory, DVD, CD, Blu-ray, etc. storing thesoftware and/or firmware. Further still, the example platforms 100, 200of FIGS. 1 and/or 2 may include one or more elements, processes and/ordevices in addition to, or instead of, those illustrated in FIGS. 1and/or 2, and/or may include more than one of any or all of theillustrated elements, processes and devices.

Flowcharts representative of example machine readable instructions forimplementing the platforms 100, 200 FIGS. 1 and/or 2 are shown in FIGS.3, 4, 9-11, and 14. In these examples, the machine readable instructionscomprise programs for execution by a processor such as the processor1512 shown in the example processing platform 1500 discussed below inconnection with FIG. 15. The programs may be embodied in software storedon a tangible computer readable storage medium such as a CD-ROM, afloppy disk, a hard drive, a digital versatile disk (DVD), a Blu-raydisk, or a memory associated with the processor 1512, but the entireprograms and/or parts thereof could alternatively be executed by adevice other than the processor 1512 and/or embodied in firmware ordedicated hardware. Further, although the example programs are describedwith reference to the flowcharts illustrated in FIGS. 3, 4, 9-11, and14, many other methods of implementing the example platforms 100, 200may alternatively be used. For example, the order of execution of theblocks may be changed, and/or some of the blocks described may bechanged, eliminated, or combined.

As mentioned above, the example processes of FIGS. 3, 4, 9-11, and 14may be implemented using coded instructions (e.g., computer readableinstructions) stored on a tangible computer readable storage medium suchas a hard disk drive, a flash memory, a read-only memory (ROM), acompact disk (CD), a digital versatile disk (DVD), a cache, arandom-access memory (RAM) and/or any other storage device and/orstorage disk in which information is stored for any duration (e.g., forextended time periods, permanently, brief instances, for temporarilybuffering, and/or for caching of the information). As used herein, theterm tangible computer readable storage medium is expressly defined toinclude any type of computer readable storage and to exclude propagatingsignals. Additionally or alternatively, the example processes of FIGS.3, 4, 9-11, and 14 may be implemented using coded instructions (e.g.,computer readable instructions) stored on a non-transitory computerreadable storage medium such as a hard disk drive, a flash memory, aread-only memory, a compact disk, a digital versatile disk, a cache, arandom-access memory and/or any other storage device and/or storage diskin which information is stored for any duration (e.g., for extended timeperiods, permanently, brief instances, for temporarily buffering, and/orfor caching of the information). As used herein, the term non-transitorycomputer readable medium is expressly defined to include any type ofcomputer readable medium and to exclude propagating signals. As usedherein, when the phrase “at least” is used as the transition term in apreamble of a claim, it is open-ended in the same manner as the term“comprising” is open ended. Thus, a claim using “at least” as thetransition term in its preamble may include elements in addition tothose expressly recited in the claim.

FIG. 3 is a flowchart representative of example machine readableinstructions 300 which may be executed to implement the example platform100 of FIG. 1 to perform secure data integrity checks. The exampleinstructions 300 of FIG. 3 are performed by an agent such as the exampledata integrity check application 106 in cooperation with the exampledata storage device 102 of FIG. 1.

The example instructions 300 begin by establishing a secure tunnel(e.g., the secure tunnel 132, 144 of FIG. 1 with the data storage device102 (e.g., via the trusted operations 158, the trusted signature 160,and/or the trusted API 128 of FIG. 1) (block 302). The example securetunnel 132 enables the application 106 to access the secure storage 124via the trusted system firmware 130.

The example hash generator 152 determines whether to generate hashes(e.g., hashes of data to be used for data integrity checks) (block 304).Generating hashes may be performed, for example, before and/or afterevents such as updates to software or data (e.g., files). If the hashgenerator 152 is to generate hashes (block 304), the example hashgenerator 152 requests baseline data (e.g., baseline data 134 of FIG. 1)from the data storage device 102 (block 306). The example request may bemade via the secure tunnel 132, the trusted API 128, and the trustedoperations 158. The example hash generator 152 receives the requestedbaseline data 134 from the storage device via the secure tunnel 132(block 308). By sending the request and receiving the baseline data 134via the secure tunnel 132, the example application 106 may trust thereceived baseline data (e.g., rely on the baseline data being authenticand/or not affected by malware).

The example hash generator 152 generates a hash of the received baselinedata 134 (block 310). The hash generator 152 stores the generated hashin the secure storage 124 via the secure tunnel 132 (e.g., as a securehash 136) (block 312). As a result, the secure hash 136 is notaccessible to malware operating at or above the kernel level and may betrusted for future operations such as data integrity checks.

After storing the hash in the secure storage 124 (block 312), or if theapplication 106 does not generate hashes (block 304), the example dataintegrity checker 154 determines whether a data integrity check is to beperformed (block 314). If the example data integrity checker 154 is toperform a data integrity check (block 314), the data integrity checker154 requests trusted data (e.g., a secure hash 136) from the storagedevice 102 (e.g., from the secure storage 124 via the trusted operations158, the secure tunnel 132, the trusted API 128, and/or the trustedfirmware 130) (block 316). The example data integrity checker 154receives the trusted data via the secure tunnel 132 (block 318).

The example data integrity checker 154 also receives data to be checked(block 320). The data to be checked may be representative data such as ahash for data to be checked for malicious and/or non-malicious butundesired changes. The example data integrity checker 154 compares thetrusted data to the untrusted data (block 322). For example, the dataintegrity checker 154 may compare a secure hash 136 to a non-secure hash138. Additionally or alternatively, the data integrity checker 154 maycompare baseline data 134 to visible data 140 (e.g., in the visiblestorage 126 of FIG. 1).

The example data integrity checker 154 applies rule(s) to the result ofthe comparison (block 324). Example rules may include malwaredefinitions such as signatures that may be present when malware is on asystem. Multiple comparisons may be necessary for some rules and/ormultiple rules may be necessary to detect malware. The example reportgenerator 156 of FIG. 1 generates report(s) based on the application ofthe rule(s) to the comparison (block 326). For example, the reportgenerator 326 may generate and issue a report to a system administratorwhen malware or other undesired data changes are detected.

After generating the report(s) (block 326) or if a data integrity checkis not performed (block 314), the example instructions 300 may end. Insome examples, the blocks 304-312 and/or the blocks 314-326 may beiterated to generate multiple hashes and/or to perform data integritychecks on multiple units of data (e.g., data files, blocks of data,etc.).

FIG. 4 is a flowchart representative of alternative example machinereadable instructions 400 which may be executed to implement the exampleplatform 200 of FIG. 2 to perform secure data integrity checks. Theexample instructions 400 of FIG. 4 are performed by a data storagedevice such as the example data storage device 202 (e.g., the datastorage device firmware 208 and the SoC 118) in cooperation with anexample agent (e.g., the data integrity check application 206) of FIG.2.

The example data storage device 202 begins by establishing a securetunnel (e.g., the secure tunnel 224) with an agent (e.g., the dataintegrity check application 206) (block 402). The example secure tunnel224 may be established between the example command generator 220 and theexample trusted API 128 of FIG. 2. The example data storage device 202(e.g., via the embedded file awareness firmware 214) obtains file systeminformation (e.g., file system information for the storage area 122, thesecure storage 124, and/or the visible storage 126) (block 404). Thefile system information informs the embedded file system awarenessfirmware 214 how to interpret the files stored in the storage area 122.

The example trusted storage firmware 130 of FIG. 2 determines whether acommand has been received (block 406). Commands may be received from thecommand generator 220 of FIG. 2 via the secure tunnel 224. If a commandhas not been received (block 406), control loops to block 406 tocontinue monitoring for a command.

When a command is received (block 406), the example hash generator 210determines whether the command is a command to generate a hash (block408). Commands to generate hashes may be received from the exampleapplication 206 when, for example, a file or program has been updatedand a new representative hash must be generated. In some examples, thecommand specifies trusted data(s) (e.g., in the secure storage 124) forwhich a hash is to be generated. If a command to generate a hash isreceived (block 408), the example hash generator 210 generates a hash oftrusted data (block 410). The example hash generator 210 then stores thegenerated hash in the secure storage 124 (block 412).

After storing the hash (block 412), or if a command to generate a hashhas not been received (block 408), the example data integrity checker212 of FIG. 2 determines whether a command to perform a data integritycheck has been received (block 414). A command to perform a dataintegrity check may specify particular data to be checked and/or maycause a data integrity check of a set or subset of data. If a dataintegrity check command has not been received (block 414), controlreturns to block 406 to monitor for a received command.

If a command to perform a data integrity check is received (block 414),the example hash generator 210 generates a hash of untrusted data (e.g.,data visible to the operating system 204) (block 416). The example dataintegrity checker 212 compares the hash of the trusted data to the hashof the untrusted data (block 418). The example data integrity checker212 applies rule(s) to the result of the comparison (block 420). Therule(s) may identify changes indicating the presence of malware or otherundesired changes to the trusted data. The example data integritychecker 212 provides the result of the rule(s) (and/or the result of thecomparison of the data) to the agent 206 via the secure tunnel 224(block 422). The agent 206 may, for example, generate a report based onthe rule(s).

To perform blocks 410, 412, and/or 416-422, the example hash generator210 and the example data integrity checker 212 may use the embedded filesystem firmware 214 to interpret the files in the storage area 122.

After providing the result (block 422), the example instructions 400 mayend. In some examples, the data storage device 202 of FIG. 2 iteratesthe instructions to continue calculating hashes and/or performing dataintegrity checks.

FIG. 5 illustrates an example agent 502 to communicate information to asecure storage system 504 using a tunnel 510. An authorized agent 502(that is executing the operating system such as the operating systems104, 204 of FIGS. 1 and/or 2) securely communicates with a securestorage system 504 using a mailboxing-based tunnel 510. For example, thesecure storage system 504 may be the data storage devices 102, 202 asdescribed in FIGS. 1 and/or 2. In some examples, the agent 502 isauthorized to communicate with secure storage 504. The example tunnel510 of FIG. 5 is based on a mailboxing scheme, in which requestedactions of the secure storage system 204 are written to a dedicated areain the secure storage system 504 referred to as the action logical blockaddress (LBA) 506. Results of requested actions are communicated using aresults LBA 508, which is a dedicated area of secure storage system 504.In some examples, the LBAs are beyond an addressable storage (e.g., theOS-visible storage 126 of FIGS. 1 and/or 2). In these examples, astorage address that is below an upper storage address can be seen by anoperating system such as operating systems 104, 204 of FIGS. 1 and/or 2.Both of the LBAs 506, 508 are above the address space that is accessibleby an operating system, so the LBAs 506, 508 (and, thus, the data storedat the LBAs) are not visible to the operating system 104, 204.

The example agent 502 of FIG. 5 can access the data and/or write to thedata from these LBAs by using a tunnel 510. The example action LBA 506is used to communicate action requests to the storage system 504.Example action requests include write, read, and/or tunnel configurationcommands, and/or other commands for accessing and/or managing data in astorage system. The results of the commands are stored in the resultsLBA 508.

In an operational example, the agent 502 is to write data to the securestorage system 504. The example agent 502 writes a write command to theaction LBA 506 and writes the data that the agent 502 wishes to store tothe results LBA 508. The secure storage system 504 processes the commandstored in the action LBA 506. Based on the command, the secure storagesystem 504 stores the subject data of the command to the locationindicated in the action LBA 506 by redirecting the subject data beingwritten to results LBA 508. In another example, the agent 502 wishes toread data from secure storage system 504. The agent 502 writes the readcommand into the action LBA 506. The example secure storage system 504processes the read command and redirects the data to be read as if thedata were to be delivered from the result LBA 508. The example agent 502reads the data from result LBA 508 to complete the read command. In someexamples, the mailboxing-based tunnel 510 can be built upon differentstorage protocols (e.g., trusted send/receive, overloaded write/read,Common Storage Management Interface (CSMI), etc.).

FIG. 6 illustrates another example agent 602 to communicate informationto a secure storage system 604 using a tunnel 606. In the example ofFIG. 6, the tunnel 606 is based on a trusted send messaging system withthe agent 602. The example agent 602 of FIG. 6 is authorized in an OS(e.g., the operating systems 104, 204) to securely communicate with thesecure storage system 604 using a tunnel 606 based on a trusted sendfacility. In some examples, the tunnel 606 is based on the trusted sendfacility of secure SATA. In such examples, the agent 602 negotiates asession key with the secure storage system 604, where the session keycan be used for transmitting messages between the agent 602 and thesecure storage system 604 (e.g., via the trusted API 128 of FIGS. 1and/or 2). In some examples, the negotiated session key is used toencrypt/decrypt the data stored in each message transmitted using thetunnel 606.

FIG. 7 illustrates an example communication from an agent 702 to asecure storage device 704 (e.g., the secure storage area 124 of FIGS. 1and/or 2, the secure storage system 504 of FIG. 5) using mailboxing. Inthe example of FIG. 7, the agent 702 is authorized by an OS to write acommand to an action LBA 706 to initiate an action 708 with the securestorage device 704. In the example of FIG. 7, the action written toaction LBA 706 contains an authorization message field 710A, a commandcode 710B, a command sequence number 710C, operators 710D, and a packageintegrity field 710E. The example authorization message field 710Aincludes data that is used to identify and authorize the actionrequested by the agent 702. For example, the authorization message field710A of FIG. 7 includes a private key that is specific to the datacommunicated between the agent 702 and the secure storage device 704.

The example command code 710B is a code that indicates what type ofcommand is being written to the action LBA 706. For example, the commandcode 710B can be a code that writes, reads, configures, and/or anothercommand code used to indicate another type of action to access and/ormanage the data stored in the secure storage device 704. The examplecommand sequence number 710C is a number that can be used to identify aspecific command message. The example operators 710D are flags or bitsthat signal firmware in the secure storage device 704 (e.g., the datastorage device firmware 116, 208 of FIGS. 1 and/or 2) to take some kindof specific action associated with a given command type. The examplepacket integrity field 710E is data that is used to ensure the integrityof the data written to the action field 710A. For example, the data inthe packet integrity field 710E may be a checksum or some other form ofdata that ensures that the data was correctly written to the action LBA706.

FIG. 8 illustrates another example communication from a secure storagedevice 804 to an agent 802 using mailboxing. The example agent 802 isauthorized by an OS to read the data from a results LBA 806 in thesecure storage device 804 to retrieve the results 808 from an actionwritten to an action LBA (e.g., the action LBA 706 of FIG. 7). Theexample results LBA 806 includes an authorization message 810A, acommand code 810B, a command sequence 810C, operators 810D, and data810E. The example authorization message 810A, the example command code810B, the example command sequence 810C, and the example operators 810Dperform the same function as described above with reference to FIG. 7.The example data 810E is used to communicate data that results from theaction that was written to the action LBA 706. The example data may beretrieved from the results LBA 806 differently (e.g., directly throughthe secure tunnel, etc.). For example, the data 810E may include thedata that is retrieved from a read. In some examples, the data 810E caninclude other data such as a return code, error code or other type ofdata that would be communicated as a result of command written to theaction LBA 706.

FIG. 9 is a flowchart representative of example machine readableinstructions 900 which may be executed to implement the example datastorage devices 102, 202, 504 of FIGS. 1, 2, and/or 5 to communicateinformation between the data storage device 102, 202 and an agent usingmailboxing. The example agent may include a data integrity checkapplication (e.g., the applications 106, 206) or another applicationoperating within an operating system (e.g., the operating systems 104,204). The example instructions 900 of FIG. 9 will be described withreference to the example agent 502 and the example secure storage system504 of FIG. 5. In some examples, the instructions 900 of FIG. 9 areimplemented using the trusted API 128 and the trusted system firmware130 operating on the SoC 118 of FIGS. 1 and/or 2.

The example instructions 900 begin by setting up action and results LBAs506, 508 (block 902). The example instructions may configure the actionLBA 506 and the result LBA 508 for communication with an agent 502 thatis authorized to communicate with the secure storage device 504. Forexample, the secure storage device 504 may configure the action LBA 506and the result LBA 508 to be beyond the upper limit of addresses that anoperating system can access. As a result, the example agent 502 isrequired to use an alternate channel of communication such as a tunnel510 to communicate information via the action LBA 506 and/or the resultsLBA 508.

The example secure storage device 504 monitors the action LBA 506 todetermine if an action has been written to the action LBA 506 (block904). For example, the agent 502 may write an action to perform a read,write, or other type of action with the secure storage device 504. Theexample secure storage device 504 monitors the action LBA 506 byscanning and analyzing incoming commands for specific bit patterns. Theexample secure storage device 504 determines whether data is written tothe action LBA 506 (block 906). If data has been written to the actionLBA 506 (block 906), the example secure storage device 504 retrieves thecommand that was written to the action LBA 506 (block 908). The exampledata written to the action LBA 506 has a data structure includingexample fields 710A-710E as described above with reference to FIG. 7.The example secure storage device 504 processes the retrieved command(block 910). After processing the command (block 910), or if data hasnot been written to the action LBA 506 (block 406), control returns toblock 404 to continue monitoring the action LBA 506.

FIG. 10 is a flowchart representative of example machine readableinstructions 1000 which may be executed to implement the example datastorage device of FIGS. 1 and/or 2 to process mailboxing communicationcommands. The example agent may include a data integrity checkapplication (e.g., the applications 106, 206) or another applicationoperating within an operating system (e.g., the operating systems 104,204). The example instructions 1000 of FIG. 10 will be described withreference to the example agent 502 and the example secure storage system504 of FIG. 5. In some examples, the instructions 1000 of FIG. 10 areimplemented using the trusted API 128 and the trusted system firmware130 operating on the SoC 118 of FIGS. 1 and/or 2.

The example secure storage device 504 decodes the command (block 1002).For example, the secure storage device 504 decodes the command byretrieving the authorization message (e.g., the authorization message710A of FIG. 7) from the command. The secure storage device 504 mayfurther determine whether the command is authorized by analyzing theauthorization message 710A.

If the secure storage device 504 determines the command is a writecommand (block 1004). The example secure storage device 504 maydetermine the type of command by reviewing the data in the command codefield (e.g., command code field 710C as described with reference to FIG.7). If the command is a write command (block 1004), the example securestorage device 504 directs the data that is to be written in the resultsLBA 508 to the storage location indicated in the command (block 1006).

If the command is not a write command (block 1004), the example securestorage device 504 determines if the command is a read command (block1008). If the command is a read command (block 1008), the example securestorage device 504 redirects the read from the results LBA 508 to astorage location specified in the command (block 1010).

If the command is not a read command (block 1008), the example securestorage device 504 determines if the command is a configure command(block 1012). If the command is a configure command, the example securestorage device 504 configures the tunnel according to the data in thecommand (block 1014). If the command is not a configure tunnel command(block 1012), the example secure storage device 504 takes an alternativeaction (block 1016). Example alternative actions could include ignoringthe command, storing an error code in the results LBA 508 indicating thecommand is not understood, and/or any other action.

FIG. 11 is a flowchart representative of example machine readableinstructions 1100 which may be executed to implement the example datastorage devices 102, 202 of FIGS. 1 and/or 2 to process tunnel messagesthat are transmitted using secure SATA. In contrast to the exampleinstructions 1000 of FIG. 10, the example agent and the example securestorage system may perform the example instructions 1100 to use thetrusted send facility of the secure SATA protocol to negotiate a sessionkey between an agent (e.g., the applications 114, 106, 206, the agent502 of FIGS. 1, 2, and/or 5) and a data storage device (e.g., the datastorage devices 102, 202, the secure storage system 504 of FIGS. 1, 2,and/or 5. The example instructions 1100 of FIG. 11 will be describedbelow with reference to the agent 602 and the secure storage device 604of FIG. 6.

The example secure storage device 604 establishes a tunnel 606 with theexample agent 602 (e.g., using the secure SATA trusted send facility)(block 1102). The example agent may negotiate a session key with thesecure storage device 604. In some examples, the session key is uniqueto the agent 602 and the secure storage device 604, such that data canbe securely communicated between the agent 602 and the secure storagedevice 604 using the session key. In some examples, the session key isused to identify the agent 602 to the secure storage device 604 and toencrypt/decrypt the data communicated using the tunnel 606.

The example secure storage device 604 receives a message from the agent602 (block 1104). The example message includes authentication data thatidentifies the message as originating from the agent 602 and includesauthentication credentials, such as the session key, that can be used todecrypt the data in the message. The example message may include theauthentication data such as the negotiated session key and the data thatis encrypted using that key. In the example of FIG. 11, receiving themessage at block 1104 includes decrypting the data contained in themessage so that the secure storage device 604 can process the receivedmessage.

The example secure storage device 604 determines if the received messageis a write message (block 1106). If the message is a write message(block 1106), the example secure storage device 604 processes the writemessage (block 1108). For example, the secure storage device 604 mayprocess the write message by determining which data is to be written andwhere the data is to be written to and writing that data using thelocation and data to be written from the message. In some examples, thesecure storage device 604 returns a message to the agent 602 via thetunnel 606 indicating the results of the write (e.g., success, failure,etc.).

If the received message is not a write message (block 1106) the examplesecure storage device 604 determines if the received message is a readmessage (block 1110). If the received message is a read message (block1110), the example secure storage device 604 processes the read message(block 1112). For example, the secure storage device 604 may retrievethe location of the read and that the amount of data to be read fromthat location. The example secure storage device 604 also sends amessage back to the agent 602 including the data that was read via thetunnel 606.

If the message was not a read message (block 1110), the example securestorage device 604 determines if that received message is a configuretunnel message (block 1114). If the received message is a configuretunnel message (block 1114), the example secure storage device 604configures the tunnel 606 according to configuration parameters in themessage (block 1116). The example secure storage device 604 may send areturn message back to the agent 602 via the tunnel 606 indicating thesuccess or failure of the command. If the received message is not aconfigure tunnel message (block 1114), the example secure storage device604 takes an alternative action (e.g., drops the received message, sendsa message back indicating the received message is not understood, etc.).

While the example instructions 1100 of FIG. 11 use the trusted sendfacility of secure SATA, other storage protocols that include a trustedsend facility may additionally or alternatively be used to set up atunnel between the agent 602 and the secure storage system 604.

FIG. 12 illustrates a block diagram of example file awareness firmware1200 to implement the example embedded file awareness firmware 214 ofFIG. 2. The example file awareness firmware 1200 includes a fileawareness message handler 1202 to handle messages such as theSet_fileupdate, Get_fileupdate, and/or Init_filesystem messages. Theexample file awareness message handler 1202 parses the messages to,among other things, determine the arguments for use in performing thecommands. The example file awareness firmware 1200 further includes adevice level file system 1204 for implementing a file system or portionsof a file system in the storage device (e.g., the storage device 202 ofFIG. 2). The example device level file system 1204 may be used toimplement the example device file system 228 of FIG. 2.

FIG. 13 illustrates a more detailed block diagram of the example devicelevel file system 1204 of FIG. 12. The example device level file system1204 of FIG. 13 includes device file properties 1302, device file tables1304, a device file system interface 1306, a memory management subsystem1308 (e.g., a NAND management subsystem), and a device file system cache1310.

FIG. 14 is a flowchart representative of example machine readableinstructions which may be executed to implement the example data storagedevice 202 of FIG. 2 to perform trusted operations on a system. Theexample instructions 1400 of FIG. 14 may be performed by an agent (e.g.,the applications 114, 206 of FIG. 2) in communication with data storagedevice firmware 208 of FIG. 2.

Host to device communication can be used to accomplish trustedoperations in the storage device such as computation of hashes orcomparison of hash signatures. The example agent 206 sends one or moreset file update messages to the data storage device 202 for files ofwhich the embedded file awareness firmware 214 in the storage device 202needs to be aware (block 1402). For example, the set file update (UFS1,source1.exe, properties(hrwx,dr), <10, . . . 112>) message causes the“source1.exe” file to be visible to the device file system 228 to beread by the data storage device firmware 208 and specifies that the fileis resident at LBA range from 10 to 112. Similarly, a set file update(UFS1, src1hash.out, properties(hrwx,drw), <120, . . . 122>) messagecauses the “src1hash.out” file to be visible to the device file system228 to be read by the data storage device firmware 208 and specifiesthat the file is resident at LBA range from 120 to 122.

The example agent 206 sends one or more get file update messages to thestorage device 202 (block 1404). For example, the agent 206 may send getfile update (UFS1, src1hash.out) message to make the data associatedwith the “src1hash.out” file visible to the agent 206. Any updates tothis file since the last write to this file by the agent 206 or the hostreflect these changes.

FIG. 15 is a block diagram of an example processing platform 1500capable of executing the instructions of FIGS. 3, 4, 9-11, and 14 toimplement the platforms 100, 200 of FIGS. 1 and/or 2. The platform 1500can be, for example, a server, a personal computer, a mobile phone(e.g., a cell phone), a personal digital assistant (PDA), an Internetappliance, or any other type of computing device for which dataintegrity checks may be performed.

The platform 1500 of the instant example includes a processor 1512. Forexample, the processor 1512 can be implemented by one or moremicroprocessors or controllers from any desired family or manufacturer.

The processor 1512 includes a local memory 1513 (e.g., a cache) and isin communication with a main memory including a volatile memory 1514 anda non-volatile memory 1516 via a bus 1518. The volatile memory 1514 maybe implemented by Synchronous Dynamic Random Access Memory (SDRAM),Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory(RDRAM) and/or any other type of random access memory device. Thenon-volatile memory 1516 may be implemented by flash memory and/or anyother desired type of memory device. Access to the main memory 1514,1516 is controlled by a memory controller.

The platform 1500 also includes an interface circuit 1520. The interfacecircuit 1520 may be implemented by any type of interface standard, suchas an Ethernet interface, a universal serial bus (USB), and/or a PCIexpress interface.

One or more input devices 1522 are connected to the interface circuit1520. The input device(s) 1522 permit a user to enter data and commandsinto the processor 1512. The input device(s) can be implemented by, forexample, a keyboard, a mouse, a touchscreen, a track-pad, a trackball,isopoint and/or a voice recognition system.

One or more output devices 1524 are also connected to the interfacecircuit 1520. The output devices 1524 can be implemented, for example,by display devices (e.g., a liquid crystal display, a cathode ray tubedisplay (CRT), a printer and/or speakers). The interface circuit 1520,thus, typically includes a graphics driver card.

The interface circuit 1520 also includes a communication device (e.g.,communication device 56) such as a modem or network interface card tofacilitate exchange of data with external computers via a network 1526(e.g., an Ethernet connection, a digital subscriber line (DSL), atelephone line, coaxial cable, a cellular telephone system, etc.).

The platform 1500 also includes one or more mass storage devices 1528for storing software and data. Examples of such mass storage devices1528 include floppy disk drives, hard drive disks, solid state storage,compact disk drives and digital versatile disk (DVD) drives. The massstorage device 1528 may implement the data storage devices 102, 202.

The coded instructions 1532 of FIGS. 3, 4, 9-11, and 14 may be stored inthe mass storage device 1528, in the volatile memory 1514, in thenon-volatile memory 1516, and/or on a removable storage medium such as aCD or DVD.

FIG. 16 is a block diagram of an example system-on-a-chip 1600 capableof executing the instructions of FIGS. 3, 4, 9-11, and 14 to implementthe SoC 118 of the data storage devices 102, 202 of FIGS. 1 and/or 2.The example SoC 1600 of FIG. 16 includes an application processor 1602having core(s) 1604A . . . 1604N. The example core(s) 1604A . . . 1604Nmay be general purpose cores (e.g., general purpose in-order cores,general purpose out-of-order cores, a combination of the two) and/orspecial purpose cores intended primarily for graphics and/or scientific(throughput). Thus, the example application processor 1602 may be ageneral-purpose processor, coprocessor or special-purpose processor,such as, for example, a network or communication processor, compressionengine, graphics processor, GPGPU (general purpose graphics processingunit), a high-throughput many integrated core (MIC) coprocessor(including 30 or more cores), embedded processor, or the like. Theprocessor 1602 may be implemented on one or more chips. The processor1602 may be a part of and/or may be implemented on one or moresubstrates using any of a number of process technologies, such as, forexample, BiCMOS, CMOS, or NMOS.

The memory hierarchy includes one or more levels of cache 1606A . . .1606N within the cores 1604A . . . 1604N, a set or one or more sharedcache units 1608. The set of shared cache units 1608 may include one ormore mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4),or other levels of cache, a last level cache (LLC), and/or combinationsthereof. In some examples, coherency is maintained between one or moreshared cache units 1608 and cores 1604A . . . 1604N.

In some embodiments, one or more of the cores 1604A . . . 1604N arecapable of multi-threading. A system agent 1610 includes components tocoordinate and operate the cores 1604A . . . 1604N. The system agent1610 may include, for example, a power control unit (PCU) and a displayunit. The PCU may be or include logic and components needed forregulating the power state of the cores 1604A . . . 1604N. The displayunit is for driving one or more externally connected displays.

The cores 1604A . . . 1604N may be homogenous or heterogeneous in termsof architecture instruction set; that is, two or more of the cores 1604A. . . 1604N may be capable of execution the same instruction set, whileothers may be capable of executing only a subset of that instruction setor a different instruction set.

An interconnect unit(s) 1612 is coupled to the application processor1602; the system agent 1610; a bus controller unit 1614; an integratedmemory controller unit(s) 1616; coprocessor(s) 1618 which may includeintegrated graphics logic, an image processor, an audio processor, and avideo processor; static random access memory (SRAM) 1620; a directmemory access (DMA) unit 1622; and a display unit 1624 for coupling toone or more external displays. The example coprocessor(s) 1618 include aspecial-purpose processor, such as, for example, a network orcommunication processor, compression engine, GPGPU, a high-throughputMIC processor, embedded processor, or the like.

An example method disclosed above includes establishing a secure tunnelbetween a storage device and an agent, transferring first data from thestorage device to the agent via the secure tunnel, the secure tunnel toprevent software executing in an operating system from modifying thedata, and identifying a data modification by comparing the first data tosecond data. In some examples, the first data comprises a hash oftrusted data. In some such examples, the method further includestransferring third data from the storage device to the agent via thesecure tunnel, the third data comprising a hash of untrusted data. Somesuch example methods further include generating the third data at theagent and transferring the third data from the agent to the storagedevice via the secure tunnel.

Some example methods further include transferring third data from thestorage device to the agent via the secure tunnel, the third datacomprising untrusted data. Some examples include identifying a presenceof a software application on a platform based on the comparison.

Another example method disclosed above includes establishing a securetunnel between a storage device and an agent, providing a command fromthe agent to the storage device, accessing first data at the storagedevice in response to the command, and identifying a modification todata stored on the storage device by comparing the first data to seconddata using the storage device. In some examples, comparing the firstdata to the second data comprises using at least one of a processor or asystem-on-a-chip in the storage device. In some examples, the commandcomprises at least one of a file system identification, a file nameidentification, a command to generate a hash of a file stored on thestorage device, or a command to compare a first hash value to a secondhash value.

Some example methods further include applying a rule to the comparisonat the storage device to determine whether the comparison isrepresentative of malware. Some examples include transferring a resultof the comparison from the storage device to the agent via the securetunnel.

An example system disclosed above includes a storage device comprising asecure storage area and a processor, and an agent. The agent is toestablish a secure tunnel to the storage device, obtain a requestedfirst data via the secure tunnel, the secure tunnel to prevent softwareexecuting in an operating system from modifying the data prior to theagent obtaining the first data, and identify a data modification bycomparing the requested first data to second data. In some examples, thefirst data comprises a hash of trusted data stored in the storagedevice. In some example systems, the storage device is to provide thirddata to the agent via the secure tunnel, the third data comprising ahash of untrusted data. In some such examples, the agent is to generatethe third data and provide the third data to the storage device via thesecure tunnel.

In some examples, the storage device is to store the trusted data in thesecure storage area. In some examples, the agent is to access a trustedapplication programming interface exposed by the storage device toestablish the secure tunnel. In some example systems, the agent is toobtain the second data from the storage device. In some examples, theagent comprises a file integrity checker to apply a rule to thecomparison to determine whether the comparison is representative ofmalware.

Another example system disclosed above includes a storage device and anagent. The storage device comprises a secure storage area and aprocessor. The agent is to establish a secure tunnel to the storagedevice and send a command to the storage device via the secure tunnel,where the processor is to identify a modification to data stored on thestorage device by comparing first data stored in the secure storage areato second data in response to the command. In some examples, wherein thefirst data comprises a hash of trusted data stored in the secure storagearea.

In some example systems, the second data comprises a hash of untrusteddata. In some examples, the processor is to compare a difference betweenthe first data and the second data to a malware definition to determinewhether malware is present on the system. In some examples, theprocessor is to provide a difference between the first data and thesecond data to the agent, the agent to generate a report based on thedifference.

Example tangible computer readable media are disclosed, comprisingcomputer readable instructions which, when executed, cause a processorto establish a secure tunnel between a storage device and an agent,transfer first data from the storage device to the agent via the securetunnel, the secure tunnel to prevent software executing in an operatingsystem from modifying the data, and identify a data modification bycomparing the first data to second data. In some examples, theinstructions further cause the processor to apply a rule to the datamodification to detect malware. In some examples, identifying the datamodification comprises identifying a modification to untrusted datastored on the storage device.

Example tangible computer readable media are disclosed, comprisingcomputer readable instructions which, when executed, cause a processorto establish a secure tunnel between a storage device and an agent,provide a command from the agent to the storage device, access firstdata at the storage device in response to the command, and identify amodification to data stored on the storage device by comparing the firstdata to second data using the storage device. In some examples, theagent executes on a host platform of the storage device or on a platformremote to the host platform. In some examples, establishing the securetunnel comprises exposing an application programming interface andreceiving a request to the application programming interface from theagent, the call comprising a trusted signature.

Although certain example methods, apparatus and articles of manufacturehave been described herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent.

What is claimed is:
 1. A tangible computer readable storage mediumcomprising computer readable instructions which, when executed, cause aprocessor of a storage device to at least: responsive to a command froman agent to the storage device via a secure tunnel between the storagedevice and the agent, access first data at the storage device; andidentify a modification to data stored on the storage device bycomparing the first data to second data on the storage device, the firstdata including at least one of trusted data and a hash of the trusteddata, and the second data including at least one of untrusted data and ahash of the untrusted data.